Sikkerhetshoder for web: Content Security Policy og JavaScript-kjøring

I dagens komplekse digitale landskap er sikkerheten til webapplikasjoner helt avgjørende. Et av de mest effektive forsvarsverkene mot ulike angrep, spesielt Cross-Site Scripting (XSS), er bruken av sikkerhetshoder for web. Blant disse fremstår Content Security Policy (CSP) som en kraftig mekanisme for å kontrollere hvilke ressurser en nettleser har lov til å laste for en gitt side. Denne artikkelen gir en omfattende guide til å forstå og implementere CSP effektivt for å beskytte dine webapplikasjoner og brukere.

Forståelse av sikkerhetshoder for web

Sikkerhetshoder for web er HTTP-responshoder som gir instruksjoner til nettleseren om hvordan den skal oppføre seg når den håndterer visse typer innhold. De er en avgjørende del av en dybdeforsvarsstrategi, og fungerer sammen med andre sikkerhetstiltak for å redusere risikoer.

Noen av de mest brukte sikkerhetshodene for web inkluderer:

• Content Security Policy (CSP): Kontrollerer hvilke ressurser brukeragenten (nettleseren) har lov til å laste.
• HTTP Strict Transport Security (HSTS): Tvinger nettlesere til å bruke HTTPS.
• X-Frame-Options: Beskytter mot Clickjacking-angrep.
• X-Content-Type-Options: Forhindrer sårbarheter knyttet til MIME-sniffing.
• Referrer-Policy: Kontrollerer hvor mye henvisningsinformasjon som skal inkluderes i forespørsler.
• Permissions-Policy (tidligere Feature-Policy): Tillater granulær kontroll over nettleserfunksjoner.

Denne artikkelen fokuserer primært på Content Security Policy (CSP) og dens innvirkning på kjøring av JavaScript.

Hva er Content Security Policy (CSP)?

CSP er et HTTP-responshode som lar deg definere en hviteliste over kilder hvorfra nettleseren har tillatelse til å laste ressurser. Dette inkluderer JavaScript, CSS, bilder, fonter og andre eiendeler. Ved å eksplisitt definere disse pålitelige kildene, kan du betydelig redusere risikoen for XSS-angrep, der ondsinnede skript injiseres på nettstedet ditt og kjøres i konteksten til brukernes nettlesere.

Tenk på CSP som en brannmur for nettleseren din, men i stedet for å blokkere nettverkstrafikk, blokkerer den kjøringen av upålitelig kode.

Hvorfor er CSP viktig for kjøring av JavaScript?

JavaScript er et kraftig språk som kan brukes til å skape dynamiske og interaktive nettopplevelser. Men fleksibiliteten gjør det også til et hovedmål for angripere. XSS-angrep innebærer ofte å injisere ondsinnet JavaScript-kode på et nettsted, som deretter kan brukes til å stjele brukerinformasjon, omdirigere brukere til phishingsider eller ødelegge nettstedet.

CSP kan effektivt forhindre disse angrepene ved å begrense kildene hvorfra JavaScript kan lastes og kjøres. Som standard blokkerer CSP all inline JavaScript (kode innenfor <script>-tagger) og JavaScript lastet fra eksterne domener. Du kan deretter selektivt aktivere pålitelige kilder ved hjelp av CSP-direktiver.

CSP-direktiver: Byggeklossene i din policy

CSP-direktiver definerer hvilke typer ressurser som er tillatt å laste, og kildene de kan lastes fra. Her er noen av de viktigste direktivene:

• default-src: Fungerer som en reserve (fallback) for andre hentedirektiver. Hvis et spesifikt direktiv ikke er definert, brukes default-src.
• script-src: Spesifiserer tillatte kilder for JavaScript-kode.
• style-src: Spesifiserer tillatte kilder for CSS-stilark.
• img-src: Spesifiserer tillatte kilder for bilder.
• font-src: Spesifiserer tillatte kilder for fonter.
• media-src: Spesifiserer tillatte kilder for lyd- og videofiler.
• object-src: Spesifiserer tillatte kilder for plugins (f.eks. Flash).
• frame-src: Spesifiserer tillatte kilder for rammer (<frame>, <iframe>).
• connect-src: Spesifiserer tillatte opphav for nettverksforespørsler (f.eks. XMLHttpRequest, Fetch API, WebSockets).
• base-uri: Begrenser URL-ene som kan brukes i et dokuments <base>-element.
• form-action: Begrenser URL-ene som skjemaer kan sendes til.
• upgrade-insecure-requests: Instruerer nettleseren til å oppgradere alle usikre URL-er (HTTP) til sikre URL-er (HTTPS).
• block-all-mixed-content: Forhindrer nettleseren i å laste ressurser via HTTP når siden er lastet over HTTPS.

Hvert direktiv kan akseptere en rekke kildeuttrykk, inkludert:

• *: Tillater ressurser fra hvilken som helst kilde (generelt ikke anbefalt).
• 'self': Tillater ressurser fra samme opphav (protokoll, vert og port) som dokumentet.
• 'none': Tillater ikke ressurser fra noen kilder.
• 'unsafe-inline': Tillater bruk av inline JavaScript og CSS (sterkt frarådet).
• 'unsafe-eval': Tillater bruk av eval() og relaterte funksjoner (sterkt frarådet).
• 'unsafe-hashes': Tillater spesifikke inline-hendelseshåndterere basert på deres SHA256-, SHA384- eller SHA512-hash (bruk med forsiktighet).
• data:: Tillater data:-URI-er (f.eks. inline-bilder kodet som base64).
• https://example.com: Tillater ressurser fra det spesifiserte domenet (og eventuelt port) over HTTPS.
• *.example.com: Tillater ressurser fra alle underdomener av example.com.
• nonce-{tilfeldig-verdi}: Tillater spesifikke inline-skript eller -stiler som har et samsvarende nonce-attributt (anbefalt for inline-kode).
• sha256-{hash-verdi}: Tillater spesifikke inline-skript eller -stiler som har en samsvarende SHA256-hash (alternativ til nonces).

Implementering av CSP: Praktiske eksempler

Det er to primære måter å implementere CSP på:

1. HTTP-hode: Sende Content-Security-Policy-hodet i HTTP-responsen. Dette er den foretrukne metoden.
2. <meta>-tagg: Bruke en <meta>-tagg i <head>-seksjonen av HTML-dokumentet. Denne metoden har begrensninger og er generelt ikke anbefalt.

Bruk av HTTP-hodet

For å sette CSP-hodet må du konfigurere webserveren din. De nøyaktige trinnene vil variere avhengig av serveren din (f.eks. Apache, Nginx, IIS).

Her er noen eksempler på CSP-hoder:

Grunnleggende CSP

Denne policyen tillater kun ressurser fra samme opphav:

            Content-Security-Policy: default-src 'self';
            

              
                Copy
              
            
          

Tillate ressurser fra spesifikke domener

Denne policyen tillater JavaScript fra https://cdn.example.com og bilder fra https://images.example.net:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' https://images.example.net;
            

              
                Copy
              
            
          

Bruk av nonces for inline-skript

Denne policyen tillater inline-skript som har et samsvarende nonce-attributt:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0mN0nc3';
            

              
                Copy
              
            
          

I din HTML:

            <script nonce="rAnd0mN0nc3">
 // Ditt inline-skript
</script>
            

              
                Copy
              
            
          

Merk: Nonce-verdien bør genereres tilfeldig for hver forespørsel for å forhindre at angripere omgår CSP-en.

Bruk av hasher for inline-skript

Denne policyen tillater spesifikke inline-skript basert på deres SHA256-hash:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=';
            

              
                Copy
              
            
          

For å generere SHA256-hashen kan du bruke en rekke nettbaserte verktøy eller kommandolinjeverktøy (f.eks. openssl dgst -sha256 -binary input.js | openssl base64).

Bruk av <meta>-taggen

Selv om det ikke anbefales for komplekse policyer, kan <meta>-taggen brukes til å sette en grunnleggende CSP. For eksempel:

            <meta http-equiv="Content-Security-Policy" content="default-src 'self';">
            

              
                Copy
              
            
          

Begrensninger ved <meta>-taggen:

• Kan ikke brukes til å spesifisere report-uri-direktivet.
• Har ikke like bred støtte som HTTP-hodet.
• Mindre fleksibel og vanskeligere å administrere for komplekse policyer.

CSP Report-Only-modus

Før du håndhever en CSP, anbefales det sterkt å bruke Content-Security-Policy-Report-Only-hodet. Dette lar deg overvåke virkningen av policyen din uten å faktisk blokkere noen ressurser. Nettleseren vil rapportere eventuelle brudd til en spesifisert URL, slik at du kan finjustere policyen din før du implementerer den i produksjon.

            Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report;
            

              
                Copy
              
            
          

Du må konfigurere et endepunkt på serversiden (f.eks. /csp-report) for å motta og behandle CSP-rapportene. Disse rapportene er vanligvis JSON-objekter som inneholder informasjon om det brutte direktivet, den blokkerte URI-en og andre relevante detaljer.

Vanlige CSP-feil og hvordan man unngår dem

Implementering av CSP kan være utfordrende, og det er lett å gjøre feil som enten kan svekke sikkerheten din eller ødelegge nettstedet ditt. Her er noen vanlige fallgruver du bør unngå:

• Bruk av 'unsafe-inline' og 'unsafe-eval': Disse direktivene deaktiverer i hovedsak beskyttelsen som CSP tilbyr, og bør unngås når det er mulig. Bruk nonces eller hasher for inline-skript og unngå å bruke eval().
• Bruk av *: Å tillate ressurser fra hvilken som helst kilde motvirker formålet med CSP. Vær så spesifikk som mulig når du definerer policyen din.
• Ikke teste grundig nok: Test alltid CSP-en din i report-only-modus før du håndhever den. Overvåk rapportene og juster policyen din etter behov.
• Feilkonfigurering av report-uri: Sørg for at ditt report-uri-endepunkt er riktig konfigurert for å motta og behandle CSP-rapporter.
• Unnlate å oppdatere CSP-en din: Etter hvert som nettstedet ditt utvikler seg, kan det hende at CSP-en din må oppdateres for å gjenspeile endringer i ressursavhengighetene dine.
• Altfor restriktive policyer: Policyer som er for restriktive kan ødelegge nettstedet ditt og frustrere brukere. Finn en balanse mellom sikkerhet og brukervennlighet.

CSP og tredjepartsbiblioteker

Mange nettsteder er avhengige av tredjepartsbiblioteker og -tjenester, som CDN-er, analyseverktøy og sosiale medier-widgets. Når du implementerer CSP, er det viktig å ta hensyn til disse avhengighetene og sørge for at policyen din tillater dem å laste ressurser korrekt.

Her er noen strategier for å håndtere tredjepartsbiblioteker:

• Hvitelist eksplisitt domenene til pålitelige tredjepartsleverandører: Hvis du for eksempel bruker jQuery fra et CDN, legg til CDN-ets domene i script-src-direktivet ditt.
• Bruk Subresource Integrity (SRI): SRI lar deg verifisere at filene du laster fra tredjepartskilder ikke har blitt tuklet med. For å bruke SRI må du generere en kryptografisk hash av filen og inkludere den i <script>- eller <link>-taggen.
• Vurder å hoste tredjepartsbiblioteker på din egen server: Dette gir deg mer kontroll over ressursene og reduserer avhengigheten av eksterne leverandører.

Eksempel med SRI:

            <script
 src="https://cdn.example.com/jquery.min.js"
 integrity="sha384-vtXRMe3mGCkKsTB9UMvnoknreNzcMRujMQFFSQhtI2zxLlClmHsfq9em6JzhbqQ"
 crossorigin="anonymous"></script>
            

              
                Copy
              
            
          

CSP og Single-Page Applications (SPA-er)

SPA-er er ofte sterkt avhengige av JavaScript og dynamisk kodegenerering, noe som kan gjøre implementering av CSP mer utfordrende. Her er noen tips for å sikre SPA-er med CSP:

• Unngå å bruke 'unsafe-eval': SPA-er bruker ofte malmotorer eller andre teknikker som er avhengige av eval(). Vurder i stedet å bruke alternative tilnærminger som ikke krever eval(), for eksempel forhåndskompilerte maler.
• Bruk nonces eller hasher for inline-skript: SPA-er injiserer ofte JavaScript-kode dynamisk. Bruk nonces eller hasher for å sikre at bare pålitelig kode kjøres.
• Konfigurer connect-src-direktivet nøye: SPA-er gjør ofte API-forespørsler til ulike endepunkter. Sørg for å hviteliste kun de nødvendige domenene i connect-src-direktivet.
• Vurder å bruke et CSP-bevisst rammeverk: Noen JavaScript-rammeverk gir innebygd støtte for CSP, noe som gjør det enklere å implementere og vedlikeholde en sikker policy.

CSP og internasjonalisering (i18n)

Når man utvikler webapplikasjoner for et globalt publikum, er det viktig å vurdere virkningen av CSP på internasjonalisering (i18n). Her er noen faktorer å huske på:

• Content Delivery Networks (CDN-er): Hvis du bruker et CDN for å levere nettstedets ressurser, må du sørge for å hviteliste CDN-ets domener i din CSP. Vurder å bruke forskjellige CDN-er for forskjellige regioner for å optimalisere ytelsen.
• Eksterne fonter: Hvis du bruker eksterne fonter (f.eks. Google Fonts), må du sørge for å hviteliste fontleverandørenes domener i font-src-direktivet.
• Lokalisert innhold: Hvis du serverer forskjellige versjoner av nettstedet ditt for forskjellige språk eller regioner, må du sørge for at CSP-en din er riktig konfigurert for hver versjon.
• Tredjepartsintegrasjoner: Hvis du integrerer med tredjepartstjenester som er spesifikke for visse regioner, må du sørge for å hviteliste domenene til disse tjenestene i din CSP.

Beste praksis for CSP: Et globalt perspektiv

Her er noen generelle beste praksiser for implementering av CSP, med et globalt perspektiv i tankene:

• Start med en restriktiv policy: Begynn med en policy som blokkerer alt som standard, og aktiver deretter selektivt pålitelige kilder.
• Bruk report-only-modus først: Test CSP-en din i report-only-modus før du håndhever den for å identifisere potensielle problemer.
• Overvåk CSP-rapporter: Gjennomgå CSP-rapporter regelmessig for å identifisere potensielle sikkerhetssårbarheter og forbedre policyen din.
• Bruk nonces eller hasher for inline-skript: Unngå å bruke 'unsafe-inline' og 'unsafe-eval'.
• Vær spesifikk med kildelistene dine: Unngå å bruke wildcards (*) med mindre det er absolutt nødvendig.
• Bruk Subresource Integrity (SRI) for tredjepartsressurser: Verifiser integriteten til filer lastet fra CDN-er.
• Hold CSP-en din oppdatert: Gjennomgå og oppdater CSP-en din regelmessig for å gjenspeile endringer på nettstedet og i avhengigheter.
• Lær opp teamet ditt: Sørg for at utviklerne og sikkerhetsteamet ditt forstår viktigheten av CSP og hvordan man implementerer det riktig.
• Vurder å bruke en CSP-generator eller et administrasjonsverktøy: Disse verktøyene kan hjelpe deg med å lage og vedlikeholde CSP-en din enklere.
• Dokumenter CSP-en din: Dokumenter CSP-policyen din og begrunnelsene bak hvert direktiv for å hjelpe fremtidige utviklere med å forstå og vedlikeholde den.

Konklusjon

Content Security Policy er et kraftig verktøy for å redusere XSS-angrep og forbedre sikkerheten til webapplikasjonene dine. Ved å nøye definere en hviteliste over pålitelige kilder, kan du betydelig redusere risikoen for kjøring av ondsinnet kode og beskytte brukerne dine mot skade. Implementering av CSP kan være utfordrende, men ved å følge beste praksis som er beskrevet i denne artikkelen og vurdere de spesifikke behovene til applikasjonen din og ditt globale publikum, kan du skape en robust og effektiv sikkerhetspolicy som beskytter nettstedet og brukerne dine over hele verden.

Husk at sikkerhet er en kontinuerlig prosess, og CSP er bare en brikke i puslespillet. Kombiner CSP med andre sikkerhetstiltak, som input-validering, output-koding og regelmessige sikkerhetsrevisjoner, for å skape en omfattende dybdeforsvarsstrategi.

Videre ressurser

• Content Security Policy (CSP) - MDN Web Docs
• CSP-evaluator
• Content-Security-Policy.com